The present invention relates to a method and a system for unidirectional or bidirectional unicast or multicast end-to-end data and/or multimedia stream transmissions in heterogeneous networks, wherein a network node uses a request to request a data link to one or more network nodes from a central switching unit in an IP network via an interface, wherein at least one network node is an IP network node, which network nodes are registered with a registration module of the central switching unit, and a control module of the central connecting unit is used to set up the connection between the network nodes. The invention relates particularly to a method and a system for IP-based telephony and video telephony in which IP nodes are authenticated on the basis of authentication data from an identification module prior to registration in the IP-based network.
Unidirectional or bidirectional end-to-end data and/or multimedia stream transmissions in IP networks, particularly IP-based telephony, is a technology which has developed in recent years to form a real alternative to conventional data and voice transmission, e.g. via circuit-switched telephone networks. Whereas conventional telephone calls are transmitted as a continuous data stream via a telephone network, IP-based telephony involves voice data being broken down into packets and transmitted individually via a data network. When large volumes of audio information have been broken down and transmitted via the network, these small packets are recompiled at the reception end. This allows telephone services to be combined with the data network, which dispenses with the installation and maintenance of a separate telephone network, since IP-based telephones are connected to a data network via an appropriate interface and voice data can be transmitted using suitable network protocols. A further important advantage of IP-based telecommunication over conventional telephony is the provision of new services which are possible only by virtue of the IP-based technology, and which represent an added value over conventional telephony. Among other things, IP-based telephony provides automatic encryption of the voice communication, which allows tap-proof calls. This development of IP-based telephony has also had an influence on the parallel development of IP-based video telephony as an alternative to conventional video conference technology. Today, ever faster data links allow simultaneous transmission of pictures and sound in outstanding quality. In the case of IP-based video telephony, as in the case of IP-based telephony, voice and picture data are broken down into packets, are sent via an IP-based network and are recompiled at the receiver.
At the same time, the rapid development of wireless data networks (WLAN 802.11, Bluetooth etc.) and an increasing number of what are known as hot spots in the public demand (for example at airports, railway stations, conference centers, trade-fair and exhibition grounds, much-frequented squares in towns) have resulted in IP-compatible appliances today being able to have a level of mobility which is comparable only with today's mobile radio networks (GSM, UMTS etc.). Wireless access to services such as the Internet is today already a matter of course. In addition, IP-based mobile telephones have also been supplied for some time which allow mobile IP-based telephony via a local area wireless network. These mobile IP telephones already also exist in versions with integrated cameras, meaning that again mobile IP-based video telephony is becoming within reach.
For communication setup and data interchange in telephone and/or video telephone networks, all the network components need to observe certain standards which are stipulated in protocols or protocol families. For example, the protocol E-DSS1 (Euro-ISDN) for circuit-switched telephone networks or the protocols H.323, SIP, MEGACO or MGCP for IP-based telephony and/or video telephony are known in the prior art.
One of the most frequently used protocols for IP-based telephony and/or video telephony is the session initiation protocol (SIP, IETF RFC 3261, previous RFC 2543). This was specified by the Internet Engineering Task Force (IETF) for the first time in 1999. This network protocol has a very simple structure and closely resembles the HTTP (Hypertext Transfer Protocol). It allows a communication session to be set up between two or more subscribers. However, it is a pure initiation protocol. For the data interchange, SIP-based telephone and/or video telephone systems use other protocols, particularly SDP (Session Description Protocol, IETF RFC 2327) and the RTP (Realtime Transport Protocol, IETF RFC 1889). SDP is used particularly to negotiate the audio and/or video codecs, transport protocols etc. which are to be used between the end points. The task of RTP is to transport the multimedia data stream (audio, video, text etc.), i.e. to encode the data, to break them down into packets and to send them. Communication end points in an SIP-based system are called user agents. A user agent client (UAC) is understood to mean a component which initiates an SIP request, and the user agent server (UAS) answers this request with a response. A user agent (UA) may take on the role either of the UAC or of the UAS. Requests, of which there are a limited number, are answered, in principle, by responses (around one hundred different ones). They merely bear numbers to distinguish them. A user agent sends an SIP message to an SIP proxy in advance. On the basis of the indicated address, the proxy decides where the message needs to be sent and forwards it. These proxies may, in principle, be stateless or stateful. Whereas stateless proxies merely forward messages and do not actually realize that a call is being set up, for example, stateful proxies can perform tasks which are useful for setting up a call. One of the most important tasks of a stateful proxy is the distribution of calls to various destinations: in a case of what is known as “Sequential Forking”, the possible call destinations are dialled in succession, and in the case of “Parallel Forking”, all destinations receive a message simultaneously. Another indispensable component of an SIP-based system is an SIP registrar, with which all user agents need to register. This logic unit manages a database containing information about the registered user agents and redirects requests to these destinations. Normally, the registrar and the proxy are the same module, which regulates the redirection internally without the need for messages to be interchanged.
Finally, an SIP-based system also comprises a redirect server or gateway, which ensures the connection between the IP-based telephone network and the PSTN, inter alia.
For the registration, SIP uses the register method. The UA indicates where it needs to be reached and receives confirmation with the code 200 (OK). If the user is not known, 404 (Not Found) is returned; if registration does not allow, the response is 403 (Forbidden). The prerequisite for successful registration is successful authentication of the user agent in the relevant network and a check on its authorization for required services, however. To this end, authentication and authorization methods RADIUS and/or Diameter are usually used in a SIP-based environment, these also being used for many other network functions.
The authentication protocol RADIUS (Remote Authentication Dial In User Service—IETF RFC 2138, 2868) is today used in many network units, such as routers, modem servers, switches etc. The authentication client sends its user name and its password to the RADIUS Server. The RADIUS server checks this information and authorizes the user for the system. The reason for the spread of RADIUS is, inter alia, the network units generally cannot handle a very large number of network users each having different authentication information, since this would exceed the storage capacity of the individual network units, for example. RADIUS allows a large number of network users to be managed centrally (addition, deletion of users etc.). In the case of ISPs (Internet Service Providers), for example, this is thus a necessary prerequisite for the service, since their number of users frequently comprises several thousand to several tens of thousands of users. In addition, RADIUS provides particular permanent protection against hackers. The remote authentication of RADIUS based on TACACS+ (Terminal Access Controller Access Control System+) and LDAP (Lightweight Directory Access Protocol) is relatively secure against hackers. By contrast, many other remote authentication protocols have only intermittent, unsatisfactory or totally nonexistent protection against hacker attacks. Another advantage of RADIUS is the fact that RADIUS was for a long time the de facto standard for remote authentication, which means that RADIUS is also supported by almost all systems.
As the complexity of the requested service is increased, however, RADIUS was found to be unsuitable for use in larger networks. This made it necessary to develop a new protocol. However, the Diameter protocol (IETF RFC 3588) was not redeveloped from scratch, but rather a large proportion of the RADIUS protocol was maintained and errors therein were corrected. Like RADIUS, Diameter uses attribute/value pairs (AVP) for conveying data and UDP as the transport protocol. In addition, it can be extended by adding new commands and AVPs. It is a basic protocol which meets the minimum requirements of an authentication transport protocol. It is therefore not intended to be used on its own, but rather should always be used with an application-specific extension. Diameter is a peer-to-peer protocol. The Diameter client normally initiates an authentication or authorization request from a user. The Diameter server receives this request and either responds to it or forwards it to a proxy server. The mobile node requests the required service using the authentication request message (AMR), which contains the AVPs. The information required for authentication is extracted from this message and included in Diameter AVPs. This message is forwarded to the local Diameter server, which is called AAAF. The AAAF forwards the message to the authentication home server (AAAH). If the AAAH is able to authenticate the user successfully, it sends a home agent MIP request (HAR) to a home agent. Having received the HAR, this home agent first of all processes the Diameter message and then produces the response HAA with the required data, such as session ID etc. and sends it to the AAAH. The latter produces the authentication response (AMA), which contains information for the tunneling of messages, inter alia, and sends it to the AAAF. With that, the connection is set up. The mobile IP extension furthermore defines numerous special cases, such as the handling of handoffs.
In addition to the authentication and authorization, a network for IP-based telephony and/or video telephony requires suitable billing mechanisms. TAP (Transferred Account Procedure) protocol from the GSM association's Transferred Account Data Interchange Group (TADIG) is the protocol which is known in the prior art for billing for the service demanded by mobile units in GSM networks. A very important concept in GSM networks is roaming, a method which allows a user of mobile radio to use his mobile radio not only in his original network but also in any desired network at home or abroad. However, this method requires a billing concept which can accommodate the complexity of the protocols and the various provided services without error. The billing methods for GSM networks must therefore in no way be trivial. Today, more than 400 GSM networks are in operation worldwide and it is also estimated that there are more than 20,000 individual roaming agreements in existence between the individual network operators. To allow billing, the seemingly simple idea of roaming therefore conceals an extremely complex process of information recording, information distribution and information evaluation. In this connection, the transferred account procedure (TAP) protocol is used for the interchange of roaming billing information between the individual mobile radio network service providers. On Jun. 4, 2000, TAP2 and TAP2+ were finally followed by the launch of TAP3. There are already subversions TAP3.1 and TAP3.2. TAP3 can today be denoted as the standard, although TAP is a developing protocol.
Most voice or data traffic in GSM networks enters or ends in a different network from the one the mobile user is currently in. The operator of a local network levies charges for every call which ends at one of its users, regardless of whether a landline network or a mobile radio network is involved. To simplify the charge levying, the local fixed network operators enter mutual agreements with the local mobile radio network operators. Thus, a mobile radio network operator in one country does not need to conclude an agreement with the landline network provider in another country in order to bill for a call from the mobile radio network of the first provider to the landline network of the second provider. Normally, the landline network provider in the first country has already concluded an agreement relating to billing type and charges with the landline network provider in the second country, so that the mobile radio network operator in the first country can then bill for his services via the landline network provider with an appropriate agreement. The costs are usually billed to the user either directly (retail billing) or via a service provider (wholesale billing). The type of billing for roaming-data or voice traffic between different mobile radio networks (PMN: Public Mobile Network) is effected using the TAP protocol. Roaming call records are typically produced either as TAP or as CIBER (Cellular Intercarrier Billing Exchange Roamer) records. CIBER records are used by mobile radio network operators using AMPS-based technologies, such as AMPS, IS-136 TDMA and IS-95 CDMA. TAP is used primarily by GSM/UMTS mobile radio network service providers and is the primary protocol for billing in GSM/UMTS-dominated areas.
Details of a call by a user who is in an alien network (VPMN: Visited Public Mobile Network) are registered in a mobile switching center (MSC) in the network. Every call thus produces one or more call records. The GSM standard for these records is defined in GSM 12.05, although many providers use their own formats. The call records of the MSC are transmitted to a billing system in the VPMN for billing. These call records are then converted to TAP format and are associated with the relevant user. No later than within a predefined time (e.g. 36 hours), the TAP records are sent to the relevant mobile radio network service providers. The TAP files additionally contain information relating to the provider service tariff (IOT: Inter Operator Tariff) and all other bilateral agreements and benefit schemes. The TAP records are sent directly or more usually via a billing center, such as a clearing house. When the home network operator (HPMN: Home Public Mobile Network) receives a TAP record from the VPMN, it is converted to an appropriate internal format and billed together with the normal call records of the user which it produces in the home network. In the case of wholesale billing, in which a service provider bills the costs incurred to the user, the HPMN forwards the records to the service provider, which can bill for the calls again, particularly also on the basis of its own tariffs, and produces the bill with, by way of example, call details for the user.
TAP3 supports a multiplicity of services. Today, TAP3 is used for the billing between GSM/UMTS service providers and GSM/UMTS service providers, GSM/UMTS service providers and non-GSM service providers (interstandard roaming) and GSM service providers and satellite service providers etc. The three fundamental categories of service, voice, fax and what are known as supplementary services, have already been supported since TAP1. By contrast, billing for the short message service (SMS) is less of a trivial matter on account of the use of short message service centers (SMS-C) belonging to third parties. Billing for SMS is more difficult for the following reasons: 1. A roaming user can receive an SMS while roaming (MT-SMS), 2. A roaming user can send an SMS while roaming (MO-SMS) by using his home network's SMS-C, and 3. A roaming user can send an SMS while roaming (MO-SMS) by using an alien network's SMS-C. Billing for SMS services is therefore not fully supported until TAP2+. From TAP3 onward, billing for circuit switched data, HSCSD (High Speed Circuit Switched Data) and GPRS (General Packet Radio Service) is also supported. TAP3 equally supports all value added services (VAS), such as what is known as billing for content. However, billing for value added services is frequently difficult, since it presupposes that the service provider is in agreement with the billed services. Customized application mobile enhanced logic (CAMEL) has been supported since the introduction of TAP3.4. CAMEL is particularly important for applications in prepaid services for roaming users and ought to become very important in the future. Another important application of TAP3 is support for billing based on inter operator tariff (IOT). IOT allows the home network service provider (HPMN) to check specific offers and tariffs from an alien service provider (VPMN) and to pass them on to the roaming user. Thus, by way of example, the VPMN may provide benefits or discounts for different call services or levels and the HPMN can easily verify these and adjust its tariffs. The opportunity to bill for roaming services independently of where the user is currently located is a valuable tool for mobile network service providers and prevents loss of income when a VPMN temporarily provides benefits. The TAP protocol likewise comprises detailed information, from TAP onward, regarding from where precisely a call was made, or a service was used etc., and where it was made to. This information assists in establishing a profile of the respective user on the basis of his behavior, which provides important information to adjust and optimize the services provided on the basis of the needs of the users. In particular, it can be used to provide specific location based services, such as sports or concert events etc. Finally, the returned accounts procedure (RAP) protocol means that TAP3 also allows differentiated error handling. Thus, RAP allows the HPMN to check incoming TAP files, inter alia, for validity and compliance with the TAP standard and if necessary to reject them in part without thereby losing billing for services which have been transmitted correctly.
At the interface between IP-based telephony and/or video telephony and conventional telephone networks, it is necessary, in principle, to solve similar problems to those in the case of billing for calls between two different mobile radio network operators. First, there is typically a large number of operators, and in practice it can be assumed that every one of these operators uses its own tariff model. Secondly, a customer of one operator can call arbitrary customers of another operator, which will be reflected in higher call charges. General guidelines for making compensatory payments can be found in ITU recommendation D.196, for example. For standard procedure for clearing and settlement, however, there are no publicly accessible standards and protocols. In addition, there are several providers for a clearing house which, in particular, are able to be used by mobile radio operators for billing roaming charges. However, a common feature of all of these providers is that likewise no publicly accessible standards are used.
So that it is possible to charge for a call between two providers via a central point, all providers need to use a standard protocol. For these purposes, the company TransNexus has specified the open settlement protocol (OSP), which ETSI has declared to be the standard in its TIPHON specification. OSP firstly defines a basic framework for standardized interchange of information. Secondly, the specification also consciously provides for portions of the protocol to be able to be replaced or extended. It is therefore likewise possible to incorporate special requirements and operator-specific services.
The transmission protocol used in the OSP is a combination of HTTP and S/MIME. For transmission, the POST method from HTTP is used. Although the PUT method also exists in order to transmit data to a server using HTTP, only the POST method can be used to assign the data which are also transmitted to a particular server resource which processes the data further. In addition, the content of the transmitted data comprises an S/MIME message. To align OSP messages with a clearing house, there are two modes of operation: the online mode and the bulk mode. In the online mode, there is a connection to the clearing house while a call is taking place between the various network operators. The reason for this approach is that the clearing house can perform a few tasks for setting up the call. Should, by way of example, the backend service associated with the caller have two little information about the destination of the call, the clearing house can make routing decisions and can supply a contact address for the destination gatekeeper. In addition, it is conceivable to incorporate the functionality of a service area broker (SAB) into the clearing house. The task of an SAB is to ascertain the best way to set up the call, which may involve taking into account tariffs based on the time of day and current load levels on the networks. However, the drawback of the online mode is an increase in the delay time for connection setup, because ultimately the caller's gatekeeper needs to await not only various responses from its own backing service but consequently also responses from the clearing house. In the bulk mode, on the other hand, a connection is set up to the clearing house only at prescribed times. An advantage of this method is that a process which is independent of the gatekeeper can read the CDRs from the backend service and can transmit them to the clearing house without interruption. Another advantage in contrast to the online mode is that a temporary absence of the clearing house does not result in any significant disruptions to one's own system. This is because should a transfer of CDRs be terminated or not happen, it can easily be repeated at a later time. However, a significant drawback that can be seen is that a clearing house cannot act as an SAB in the bulk mode. In addition, no routing decisions can be made by the clearing house, because this can likewise only be done in the online mode. The most important components of an OSP message are the pricing exchange, authorization exchange and usage exchange. Pricing exchange comprises the interchange of information for the costs of a telephone call. This pricing exchange comprises the transmission of a pricing indication, which needs to be confirmed with a pricing confirmation. The authorization exchange is performed when resources need to be used by the clearing house. Normally, this corresponds to authorization for the setup of a telephone call. Like the pricing exchange, the authorization exchange is also based on the transmission of an authorization request, which is confirmed with an authorization response. The usage exchange contains a description of the resources used. To this end, a usage indication is sent which is confirmed with a usage confirmation. Since the OSP still cannot distinguish any services, the term usage should be understood to mean the call time for a conducted telephone call.
IP-based telephony and video telephony in the prior art are associated with considerable drawbacks, however. Although it is possible today to authenticate the call participants in an IP-based network using authentication and authorization mechanisms as described, and to check their authorization for particular services, these authentication and authorization methods are fairly complicated and also do not meet the high standards regarding security, billing and service authorization, as are provided in the conventional telephone networks. In particular, GSM/UMTS mobile radio networks provide standards for authentication and authorization which are not able to be implemented in an IP-based network on account of its intrinsic characteristics. This is because the open architecture of the IP protocol lacks a large amount of information which is absolutely necessary for full compatibility with the GSM networks.